The standard personal computer, whether of the desktop, laptop or notebook type, includes a central processor (CPU), typically a microprocessor, such as the Intel Pentium or 486, and a keyboard controller. The computer's basic, or lowest-level, instruction set, is commonly known as the Basic Input Output System (BIOS). The BIOS, which normally comprises the basic input and output routines needed for communicating between software and hardware, is typically stored in read-only memory (ROM).
A microcontroller embedded in the keyboard is responsible to scan, debounce, interpret keystrokes and communicate with a keyboard controller mounted on the PC's main circuit board or motherboard. The keyboard controller has its own ROM from which it executes its code, commonly referred to as the keyboard BIOS. The conventional IBM-compatible PC employs two separate BIOS ROMs; one, the system BIOS ROM, contains the system BIOS instruction code and the other, the keyboard BIOS ROM, contains the keyboard BIOS instruction code.
In recent years, there has been an increased integration of additional features, capabilities and functionality on a single integrated circuit. This trend toward greater integration, which has resulted in increased power at lower cost in commercial PCs, has created an interest and a desire among PC designers to integrate both the system and keyboard BIOS in a single, unified ROM on a single chip. There has thus been an ongoing effort among PC designers to develop an interface that would allow the use of a shared BIOS ROM for access by both the host CPU and keyboard controller. Previous attempts to implement such an interface have, however, been only of limited success at least in part because of the inability of prior interface designs to make the BIOS ROM always available for the device (keyboard or host CPU) that needs to execute out of the BIOS ROM at any given time.
This problem arises from the fact that in the conventional PC, once the System Reset or CPU Reset signal has transitioned from an asserted state to a deasserted state, the host CPU will effectively begin fetching code located in BIOS ROM from its initialization address. The assertion of the CPU Reset signal may therefore occur without first informing the device that controls the shared ROM interface. If the CPU Reset signal is asserted at any time that the host CPU does not have ownership of, or access to, the ROM interface, then, following deassertion of the CPU Reset signal, the host CPU in attempting to read code from its initialization vector (mapped to the ROM space), will read incorrect data ("garbage") resulting in system misoperation and a likely system crash.
The most common and straightforward way to solve this problem would be to include dual-ported interface circuitry to arbitrate simultaneous accesses to the BIOS ROM between the host CPU and the keyboard controller. This approach, however, has several disadvantages. For example, any time the host CPU accesses the ROM it steals cycles from the keyboard controller. This is undesirable, particularly if the keyboard controller is at the time executing code that is time-dependent or critical. In addition, intersplicing the host CPU access with keyboard controller access to the BIOS ROM requires careful attention to the current state of the keyboard controller's bus cycle so that it is interrupted only on instruction boundaries, i.e., not in the middle of a Read strobe. This requires that the appropriate control signal be deasserted and held until the keyboard controller can be stopped, which typically results in an approximately two to three microseconds additional delay per access by the host CPU. A dual-ported interface that would perform this function would add a significant level of complexity and require additional cost to implement. It also may result in performance degradation for both the host CPU and the keyboard controller.